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Current  State  of  Software  Engineering 


New  systems  usually  a  heterogeneous  collection  of 
custom  and  commercial  products 

•  Integration  provided  by  some  third-party  technology 

New  systems  seldom  expected  to  function  independently 

•  Expected  to  cooperate  with  existing  systems 
(e.g.,  as  a  part  of  a  system  of  systems) 

•  Ability  to  achieve  “cooperation”  is  generally  termed 
"interoperability" 

Elements  of  these  cooperating  systems  undergo  frequent 
changes  (e.g.,  upgrades  of  commercial  products) 

Thus:  boundaries  within  and  between  systems  begin 
to  blur 

•  Distinctions  between  a  "system  of  systems"  and  a  single, 
complex,  distributed  system  disappear 
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Current  State  -  2 


Interoperability  can  occur  only  when  some  degree 
of  compatibility  exists  among  all  elements  that 
must  cooperate  in  some  purpose 

Interoperability  is  based  on  the  existence  of  (and 
cannot  occur  lacking)  a  single,  common 
conceptual  view 

*  Conceptual  view  can  be  embodied  in  an  architecture 
or  design 

*  Conceptual  view  can  be  implemented  through  a 
common  protocol 

*  Single  conceptual  view  determines  whether  a  system 
(or  system-of-systems)  can  made  to  cooperate  as 
intended 
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The  Problem  Space 


Incomplete  understanding  of  scope  and  nature  of 
the  engineering  to  be  accomplished 

•  Cannot  discern  incompatible  solutions  or 
intractable  problems 

Ongoing  inertia  toward  separate  programs, 
managed  and  executed  independently 

•  Cannot,  in  such  a  climate,  ensure  that 
independent  programs  act  in  service  of  a 
common  goal  (i.e.,  the  interoperable  end  goal) 

Few  technologies  currently  exist  that  permit 
quantification  of  any  aspect  of  interoperability 


page  5 


Carnegie  Mellon 

Software  Engineering  Institute 


An  Instance  of  the  Problem 


We  know  quite  a  lot  about 
constructing  systems  from 
components  (over  which  we  may 
have  little  or  no  control). 

We  know  something  about 
composing  systems  of  systems 
from  individual  systems  from 
individual  systems  (over  which 
we  may  have  little  or  no  control). 


We  know  very  little  about  constructing 
an  interoperable  network  of 
systems... the  key  distinction  being  that 
the  network  is  unbounded  (or  very 
loosely  bounded)  and  has  no  single 
controlling  authority. 


Unplanned,  unexpected, 
emergent  behavior  here... 
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Integrated  CASE  Environments 

Extensive  research  between  c.  1987  and  1993  to 
create  integrated  collections  of  CASE  tools 

•  Also  called  Project  Support  Environments,  Software 
Engineering  Environments,  ... 

•  Extensive  technogies  developed  to  provide 
third-party  integrating  capability 

•  PCTE  (ECMA)  and  CAIS-A  (U.S.  DoD)  were  major 
integrating  technologies 

Considerable  advance  of  knowledge  about 
integration,  but  few  tangible  instances  of  usable 
environments 

•  Three  integration  research  efforts  were  noteworthy 
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Wassermann 

Distinguished  three  (later  five)  dimensions 
of  integration 

Permits  multiple,  independent  descriptions 
of  different  facets  of  integration 
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Thomas  &  Nejmeh 

Defined  integration  as  “the  property  of  a 
relationship” 

Distinguished  between  “well  integrated” 
and  “easily  integrable” 

Provides  a  means  to  characterize  different 
aspects  of  integration  based  on  different 
human  perspectives. 
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ECMA/NIST  model 


Defined  capabilities  in  terms  of  “services”  rather  than 
implementations  or  products 

Separated  notion  of  “framework”  from  tools  and 
applications  that  depend  on  that  framework 
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NATO  C3  SAF  Model 


NATO  C3  System  Architecture  Framework  (NC3SAF) 

•  Mandated  for  NC3  systems  architectures. 

•  Includes  three  main  types  of  guidance  for  architecture 
development 

-  Guidelines  that  include  guiding  principles  for 
building  architectures 

-  Process  to  build  and  integrate  architectures 

-  Templates  with  detailed  descriptions. 

Based  on  the  DoD  C4ISR  Architectural  Framework 

•  Different  from  its  U.S.  counterpart  in  that  it  is  inclusive 
of  specific  NATO  directives,  precepts  and  tenets. 

Includes  an  extensive  discussion  of  interoperability 


page  13 


Carnegie  Mellon 

Software  Engineering  Institute 


NATO  -  2 


Levels  of  interoperability: 

•  No  Data  Exchange 

-  No  physical  connection  exists 

•  Unstructured  Data  Exchange 

-  Exchange  of  human-interpretable,  unstructured  data  (free  text) 

•  Structured  Data  Exchange 

-  Exchange  of  human-interpretable  structured  data  intended  for 
manual  and/or  automated  handling,  but  requires  manual 
compilation,  receipt,  and/or  message  dispatch 

•  Seamless  Sharing  of  Data 

-  Automated  data  sharing  within  systems  based  on  a  common 
exchange  model 

•  Seamless  Sharing  of  Information 

-  Universal  interpretation  of  information  through  cooperative 
data  processing 
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NATO  -  3 


Sub-degree  descriptions: 

Unstructured  Data  Exchange 

1  .A  Network  Connectivity  Network  connectivity  can  range  from  a 
simple  transport  line  for  file  transfer  or  basic  email  connecting  to  non- 
NATO  systems,  to  full  connectivity  with  services  required  by  the  higher 
sub-degrees.... 

I.A.IInternetworkingAII  LAN,  MAN,  WAN  Connections. 

1.A.2Secure  Internetworking  Secure  LAN,  WAN,  WAN  Connections. 
1.A.3Packet  Switch  WAN  Connecting  to  NIDTS/PTT  Packet  Network. 
1.A.4Circuit  Switched  WAN  Connecting  to  NCN,  National,  Commercial 
Switched  Network. 

1.A.5Remote  Terminal  Interactive  computer  session  from  remote 
location. 

1.A.6TADIL  CommsCommunications  for  Tactical  Link  11,16  and  22 
Data  Interchange. 

1.A.7SATCOMConnecting  to  UHF  and  EHF  Satellite  Comms. 


page  15 


Carnegie  Mellon 

Software  Engineering  Institute 


LISI  Model:  Levels  of  Interoperability 


Infant  uit ion  Exch  tinge 


Level 


Computing  Environment 


Dasl  ri  b  u  led  "Liihal  mt'oh  and  . 
Simultaneous  iiLlurm'ti n n k  11/  -camp  lev  data 
Advanced  cad  Lli  Iji)]-;i  turn 

e.g.,  Interactive  COP  update 
EvcliI -triggered  glnfoal  database  uptime 


4  —  Enterprise 

Interactive  manipulation 
Shared  data  &.  applications 


Shared  databases 
Saiphisticatcal  colljbiuatuin 

c.g.,  Common  Operational  Picture 


3  --  Domain 

Sltared  data 

“Separate”  applications 


tklLTU^cncciuK  prriainct  exeiianye 
Orinip  ■CidliLtKi  nil  i  mi 

c.g  Exchange  of  anntilatcdl  Linag.cn', 
maps  w/ overlays 


2  —  I 'i  met  ion  ft  I 

Minimal  common  functions 
Separate  data  &l  applications 


Uaimaigcncaius  pro  duel  eidn  aii^e 

c  g.,  FM  voice,  tacttcal  dala  links.. 
IcxL  file  transfers.,  messages,  e-mail 


1  —  ( ’un  netted 

Electronic  connection 
Separate  data  &  applications 


Ir 


Telnet,  FTP, 
E-Mail  Chatter 


■** 


Man  uai  C  atew  ay 
c.g„,  diskette,  tape, 
h ami  copy  exchange 


M  —  Isolated 

Non-connected 


i 
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LISI  Model:  “PAID”  Attributes 
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A  “level”  is  enabled  by  a  specific  profile  of  P,  A,  I,  &  D  attributes 
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LCIM  model 


Incorporates  notion  of  Conceptual  interoperability 

•  Explicit  focus  on  semantic  issues 

•  Maintains  concept  of  increasing  maturity,  levels,  etc. 


Level  4 

Harmonized  Data  and  Processes 
(Conceptual  Model,  Intend  of  Use) 


Common  Conceptual  Model  I 
Semantic  Consistency 


Level  3 

Aligned  Dynamical  Data 
and  “Implemented  Processes” 


Common  System  Approach  I 
Open  Source  Code 


Level  2 

Aligned  Static  Data 
through  (Meta)  Data  Management 


Use  of  Common  Reference  Models  I 
Common  Ontology 


Level  1 

Documented  Data 


Documentation  of 
Data  and  Interfaces 


Level  0 

Systems  Specific  Data 


Isolated  Systems 


page  18 


Carnegie  Mellon 

Software  Engineering  Institute 


SOSI  model 


Focus  is  on  different  domains  of  interoperability 

•  Programmatic,  Constructive,  Operational 

•  Different  kinds  of  activities  and  relationships  in  each 
domain 


Program 
Management 


Operational 

System 


Activities  performed  to  manage  the 
acquisition  of  a  system.  Focus  is  on 
contracts,  incentives,  and  practices 
such  as  risk  management. 


Activities  performed  to  create  and  sustain  a  system. 
Focus  is  on  architecture,  standards,  and  commercial 
off-the-shelf  (COTS)  products. 


Activities  performed  to  operate  a  system. 
Focus  is  on  interactions  with  other  systems 
and  with  users. 
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Some  General  Precepts 

“Interoperability”  is  a  multi-dimensional  aspect  of 
system  engineering 

•  Scope  is  far  greater  than  simply  interoperability  of 
data 

•  Encompasses  interoperablity  at  the  programmatic 
(and  other)  levels 

•  A  model  must  includes  degrees  of  coupling, 
heterogeneity,  synchronicity, . . . 

We  can  never  anticipate  fully  the  boundaries  that  a 
given  system  will  be  expected  to  operate  within 

Interoperability  must  be  quantifiable  to  be 
achievable 

Interoperability  must  be  sustainable  and  sustained 
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Proposed  Characteristics 

Based  on  observations  about  desired  types 
and  levels  of  interoperability 

Must  be  verified  and  validated  through 
scenarios  drawn  from  real  programs 

Characteristics  chosen  are  not  necessary 
discrete 

List  needs  refinement  through  further  research 
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Proposed  Characteristics  -  2 

Six  principal  characteristics: 

•  Coupling 

•  Heterogeneity 

•  Synchronicity 

•  Boundedness 

•  Ownership 

•  Usage  patterns 

May  be  more  characteristics 

•  These  may  be  at  a  lower  (or  higher) 
level  of  importance 
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Coupling 

Should  permit  modeling  the  aggregate  degree  of 
coupling  in  an  interoperating  system 

•  Coupling  among  its  elements  (i.e.,  systems) 

•  Elements  may  themselves  be  collections  of  systems 

•  Continues  recursively  until  some  base  level  of 
complexity  of  internal  coupling  within  an  individual 
system 

Aggregate  degree  of  coupling  has  implications  for 
techniques,  strategies,  difficulty,  etc.  to  create,  use, 
or  sustain  the  entire  system  of  systems. 
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Heterogeneity 

Should  permit  modeling  both  syntactic  and 
semantic  complexity 

•  Each  pair-wise  set  of  systems  will  exhibit  both 
kinds 

•  As  the  number  of  systems  grows  beyond  a  pair, 
this  complexity  grows  combinatorially 

The  degree  of  heterogeneity  (and  at  both  syntactic 
and  semantic  levels)  may  suggest  the  degree  of 
difficulty  in  achieving  and  sustaining 
interoperability  between  the  pair. 
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Synchronicity 

Should  permit  modeling  the  rates  at  which 
elements  (i.e.,  individual  systems)  undergo  change 

•  Change  includes  update,  modernization,  repair, 
and  so  forth 

•  Like  other  properties,  this  is  recursive  down  to 
the  level  of  individual  components 

The  degree  to  which  individual  systems’  rates  of 
change  are  synchronous  will  affect  the  degree  to 
which  the  aggregate  interoperability  is  sustainable 
(and  perhaps  achievable  at  all). 
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Boundedness 


Should  permit  modeling  the  degree  and  nature  of 
external  and  internal  system  boundaries 

•  Some  interoperable  systems  occurs  when  the 
aggregate  collection  of  systems  is  initially 
known 

•  Other  interoperable  systems,  actual  extent  of  the 
system-of-systems  is  known  to  be  unknown. 

Methods,  techniques,  and  technologies  used  to 
bring  about  the  aggregate  interoperation  will  likely 
be  different 

•  Ongoing  maintenance  of  the  overall  system  will 
also  differ 
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Ownership 

Should  permit  modeling  the  different  qualities  of 
authority  over  systems  and  elements  of  systems 

•  Some  complex  systems  of  systems  are  methodically 
planned  (e.g.,  U.S.  DoD’s  Future  Combat  System) 

-  Possible  (or  should  be)  to  identify  some  controlling 
agency  of  the  overall  system(s) 

•  Some  interoperability  occurs  opportunistically,  when 
two  (or  more)  diverse  systems  are  linked  in  unplanned 
but  useful  ways 

-  Usually  impossible  to  identify  any  agency  with 
responsibility  for  the  overall  aggregate  system 

Will  generally  be  very  different  processes, 
techniques,  and  methods  used  to  bring  about  the 
interoperability  between  the  constituent  systems 
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Usage  Patterns 

Should  permit  modeling  the  conformity  between 
intended  and  actual  usage  patterns  throughout  the 
system 

•  All  elements  of  any  system  (i.e.,  components,  entire 
systems)  have  an  intended  pattern  of  use 

•  An  interoperating  set  of  systems  also  has  an  intended 
pattern  of  use 

-  This  will  conform  to  usage  patterns  of  some 
elements,  and  conflict  with  usage  patterns  of  other 
elements 

Aggregate  degree  of  harmony  and  conflict  may 
determine  the  usability  and  robustness  of  the 
overall  system 

•  This  characteristics  will  be  inconsistent  across  the 
system’s  elements 
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Conclusion 


Appropriate  models  have  proven  to  be  of 
considerable  value  in  many  engineering 
domains 

We  are  presently  in  need  of  such  models  for 
integrating  collections  of  software  systems 

Current  efforts  have  produced  several 
interesting  and  useful  models 
*  Much  more  work  is  needed 
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Conclusion  -  2 


Trend  toward  ever-increasing  intercon¬ 
nection  between  systems  will  continue 

Nature  and  quality  of  these  intercon¬ 
nections  will  be  governed  by  decisions 
now  being  made 

Effects  of  these  decisions  may  be  long- 
lasting 
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